The 3rd Generation Partnership Project (3GPP) is a collaboration between groups of telecommunications associations, to make a globally applicable third generation (3G) mobile phone system specification within the scope of the International Mobile Telecommunications-2000 project of the International Telecommunication Union (ITU). FIG. 1 illustrates a 3GPP architecture for multiple access in a non-roaming scenario, and FIG. 2 illustrates a 3GPP architecture for multiple access in a roaming scenario. The architectures depicted in FIGS. 1 and 2 show the scenarios in which a client-based mobility protocol S2c—i.e., DSMIPv6 (Dual stack Mobile IPv6)—is used for connectivity and mobility between 3GPP accesses and non-3GPP accesses. S2c is described in more detail in 3GPP TS 23.402, which is incorporated herein by reference. The mechanisms specified in 3GPP TS 23.402 can be used to connect a user equipment (UE) (or mobile terminal) in parallel to an evolved packet core (EPC) via a 3GPP access network and a non-3GPP access network towards different packet data networks (PDNs).
Two Internet Engineering Task Force (IETF) specifications—IETF draft-ietf-monami6-multiplecoa-08, and IETF draft-ietf-mext-flow-binding-00a—describe techniques for supporting multiple IP flows over different accesses. The techniques are based on Extensions to DSMIPv6 where a UE can perform multiple CoA (Care-of Address) registrations for the same HoA (Home Address) with the HA (Home Agent), and traffic is routed to the different CoAs based on flow binding (i.e., traffic descriptors that filter the traffic and route the traffic to the correct CoAs—downlink packets addresses to the UE are received by the HA, the filters are applied, and packets are routed towards the CoA corresponding to the matching filter). It is therefore possible to extend S2c in 3GPP (i.e., the interface based on DSMIPv6) in order to allow a UE to be connected simultaneously to the same PDN via different accesses and to move IP flows between the different accesses.
Specifically, the techniques include the following features. Multiple DSMIPv6 CoAs registrations occur at the DSMIPv6 level with the HA (Home Agent)/PGW (PDN Gateway). The different CoAs are obtained over different access networks. The different CoAs are then used simultaneously by the UE. One Binding Cache Entry (BCE) is created for each CoA. The mapping between HoA and CoA is no more a one-to-one but one to many. DSMIPv6 BUs (Binding Update messages) can contain more than one CoAs. A BID (Binding Identifier) is used to univocally identify the HoA-CoA mapping. A BU (Binding Update) contains as many BID options as the number of CoAs in the BU. DSMIPv6 BUs can contain description of flows associated with each CoA. Each BU can contain a FID (Flow ID) option. The FID option includes a flow identifier and a flow description and a pointer to the respective BID. The routing of UL (uplink) and DL (downlink) packets is performed based on these associations. For example, FIG. 3 illustrates an example binding cache in a home agent (HA)/packet data network gateway (PGW) when multiple CoAs are registered for the same HoA with different binding descriptors.
The techniques described in the IETF specifications mentioned above, however, do not apply completely to 3GPP networks. In fact, in 3GPP some accesses (typically the 3GPP specific access technologies, e.g., WCDMA or LTE) are considered “home link” from a DSMIPv6 point of view. What that means is that the UE, when connected over such access technologies, shall not use a DSMIPv6 tunnel to obtain connectivity. This is represented in FIGS. 1 and 2 by the presence of a dotted line S2c interface (e.g., DSMIPv6) that indicates that only DSMIPv6 signaling can be exchanged over 3GPP accesses, but no DSMIPv6 tunneling is used. FIGS. 4 and 5 respectively illustrate this scenario.
In FIG. 4, Access #1 corresponds to the home link for the UE from a DSMIPv6 perspective (e.g., Access #1 is the serving gateway in a 3GPP architecture), and Access #2 is not the home link. Because the UE is on the home link, no CoA is assigned to the UE and, therefore, there are no mappings between an HoA and CoAs. Accordingly, both IP flows A and B are routed through Access #1. In FIG. 5, Access #1 corresponds to the home link for the UE from a DSMIPv6 perspective (e.g., Access #1 is the serving gateway in a 3GPP architecture), and Access #2 is not the home link. For IP flow B, the UE is on the home link for DSMIPv6, therefore, no CoA is assigned. For IP flow A, the UE is not on the home link for DSMIPv6, therefore, a CoA1 is assigned. A mapping between the HoA and CoA1 must be created (including traffic filters/descriptors) at the HA/PGW.
Current techniques for providing multiple accesses to a UE are based on the idea that when a UE is connected to a PDN over two accesses, the UE is assigned one CoA over each access. In practice, there is presently no way to allow a BCE (binding cache entry) that would have flow descriptors for directing traffic either to the CoA or to the HoA, since no BCE is created unless there is a CoA, and therefore an entry for the HoA cannot be created. In FIGS. 1 and 2 the UE is connected on the home link when the UE is using a 3GPP access, and is not on the home link when using a non-3GPP access. In such scenario the UE is provided connectivity either using PMIPv6 (Proxy Mobile IPv6) over an S5 interface, or the GTP (GPRS Transport Protocol) protocol.
An additional scenario is when a UE can also be connected via two-home links is shown in FIG. 6. As shown in FIG. 6, IP flow A is routed through a first home link on Access #1, IP flow B is routed through a second home link on Access #2, and IP flow C is routed through a non-home link on Access #3. Regarding IP flow C, the UE is not on the home link, therefore, a CoA1 is assigned to the UE.
In such case, in fact, the UE using simultaneously a 3GPP access (where the connectivity is provided either with PMIPv6 or GTP) and a non 3GPP access and being connected over the non-3GPP access using PMIPv6 (i.e., S2a or S2b are used and they use PMIPv6) as described in FIGS. 8 and 9. In such case, the UE is on two home links from a point of view of DSMIPv6, and no DSMIPv6 tunneling shall be used. This specific scenario is not described in this invention. However an extended scenario where the UE is connected on two access that are home link for the UE and a third access that is not home link for the UE is described.
A final component of the problem is related to the scenario where the UE connects first on a link that is not home link (i.e. a non-3GPP access using DSMIPv6) and subsequently to a 3GPP access. In current specifications, when the UE connects to a 3GPP access, the UE performs an attach procedure. Two types of attach procedures are defined—an “initial attach” and a “handover”.
“Initial attach”: during the attach procedure, the UE provides an indication of Attach Type as “initial attach”. This is used when the UE is actually connecting to the network for the first time and therefore it has no IP address allocated (i.e., no HoA) nor a PDN GW/HA is allocated to serve the UE. In such case, the network selects a new PDN GW and assigns a new HoA to the UE. “Handover”: during the attach procedure, the UE provides an indication of Attach Type as “handover”. This is used when the UE is actually already connected over another access and it is handing over the connection to the 3GPP access. In such case the UE has an IP address allocated (i.e., HoA) over the previous access and a PDN GW/HA is allocated to serve the UE. In such case, the network does not select a new PDN GW and does not assign a new HoA to the UE, but simply switch the connectivity from the old access to the new access.
FIG. 8 illustrates a procedure 800 including steps involved in an initial attach, which steps are further described in 3GPP TS 23.401 (which is incorporated herein by reference). Note that the procedure for initial attach over 3GPP is repeated also during handover from non-3GPP, as described in the steps, and shown in FIGS. 9 and 10.
Referring first to FIG. 8, note that for a PMIP-based 55/58, procedure steps (A), (B), and (C) are defined in TS 23.402. Steps 7, 10, 14, 15 and 16 concern GTP based S5/S8. Also note that the steps in (D) are executed only upon handover from non-3GPP access. Additionally, only the key steps of FIG. 8 are described below. At step 1, the UE initiates the Attach procedure by the transmission, to the eNodeB, of an Attach Request (IMSI or old GUTI, . . . , Attach Type, . . . ) message. Attach Type indicates “Handover” when the UE has already an activated PDN GW/HA due to mobility with non-3GPP accesses. The eNodeB . . . forwards the Attach Request message to the new MME (step 2).
At step 13, if the PDN subscription context contains a dynamically allocated PDN GW identity and the Attach Type does not indicate “Handover”, the MME may select a new PDN GW as described in clause PDN GW selection function, e.g., to allocate a PDN GW that allows for more efficient routing. If the PDN subscription profile contains no PDN GW address for the default PDN and the Attach Type indicates “Handover”, the MME select a new PDN GW as described in clause PDN GW selection function. The new MME selects a Serving GW, then the new MME sends a Create Default Bearer Request ( . . . , PDN GW address, PDN Address, . . . , Handover Indication, . . . ) message to the selected Serving GW. Handover Indication is included if the Attach type indicates handover.
At step 14, the Serving GW sends a Create Default Bearer Request ( . . . , PDN Address, . . . , Handover Indication, . . . ) message to the PDN GW indicated by the PDN GW address received in the previous step. At step 15, if dynamic PCC is deployed, and the Handover Indication is not present, the PDN GW performs an IP-CAN Session Establishment procedure as defined in TS 23.203, and thereby obtains the default PCC rules for the UE. If dynamic PCC is deployed and the Handover Indication is present, the PDN GW executes a PCEF-Initiated IP-CAN Session Modification procedure with the PCRF as specified in TS 23.203 to obtain the rules required for the PDN GW in the VPLMN or HPLMN to function as the PCEF for all the active sessions the UE has established with the new IP-CAN type as a result of the handover procedure. If, however, dynamic PCC is not deployed, the PDN GW may apply local QoS policy.
At step 16, the PDN GW returns a Create Default Bearer Response ( . . . ) message to the Serving GW when the Handover Indication is present, the PDN GW does not yet send downlink packets to the SGW; the downlink path is to be switched at step 22a. At step 22, the new MME sends an Update Bearer Request ( . . . , Handover Indication) message to the Serving GW. At step 22a, if the Handover Indication is included in step 22, the Serving GW sends an Update Bearer Request (Handover Indication) message to the PDN GW to prompt the PDN GW to tunnel packets from non 3GPP IP access to 3GPP access system and immediately start routing packets to the Serving GW for the default and any dedicated EPS bearers established. At step 22b, the PDN GW acknowledges by sending Update Bearer Response to the Serving GW.
At step 23, the Serving GW acknowledges by sending Update Bearer Response (EPS Bearer Identity) message to the new MME. The Serving GW can then send its buffered downlink packets. At step 24, after the MME receives Update Bearer Response (EPS Bearer Identity) message, if Attach type does not indicate handover, and an EPS bearer was established and the subscription data indicates that the user is allowed to perform handover to non-3GPP accesses, and if the MME selected a PDN GW that is different from the PDN GW identity which was indicated by the HSS in the PDN subscription context, the MME shall send an Update Location Request including the APN and PDN GW identity to the HSS for mobility with non-3GPP accesses. Note that in the case of a handover from a non-3GPP access, the PDN GW initiates resource allocation deactivation procedure in the trusted/untrusted non-3GPP IP access.
Step 8 of FIG. 8 results also in storing in PCC the IP-CAN indication for the connection (i.e. 3GPP access). In case of UE connected first to an access that is not home link and then connecting to an access that is home link (i.e. a 3GPP access) and moving some flows from the non-3GPP access to the 3GPP access, neither indication works. In fact: “Initial attach”: since in such case the network selects a new PDN GW and assign a new HoA to the UE, the UE ends up with a different HoA and cannot moves the flows over from the non-3GPP access. “Handover”: in this case the network would typically switch the connectivity from the old access to the new access if the old access is connected using PMIP, since “Handover” is used to provide IP address preservation, and the UE would then delete the S2c BCE at the end of the handover. FIGS. 9 and 10 describe this type of handover as currently defined where all the flows are being moved to the new access.
Regarding the steps shown in FIG. 9, the UE uses a trusted or untrusted non-3GPP access system (step 1). For example, the UE can have a DSMIPv6 session with the PDN GW. In step 2, the UE discovers and attaches to the 3GPP access. In step 3, the UE sends a BU (lifetime) to the PDN GW to de-register its DSMIPv6 binding, as defined in draft-ietf-mip6-nemo-v4traversal (which is incorporated herein by reference) that was created while the UE was in non-3GPP access system. The PDN GW responds with a BA message as defined in draft-ietf-mip6-nemo-v4traversal. Step 3 corresponds to deleting the BCE for the connection with S2c over the old link.
Referring to FIG. 10, in step 1, the UE uses a trusted or untrusted non-3GPP access system and is served by a PDN GW (as PMIPv6 LMA or MIPv4 HA). In step 2, the UE discovers the E-UTRAN access and determines to transfer its current sessions (i.e., handover) from the currently used non-3GPP access system to E-UTRAN. In step 3, the UE sends an Attach Request to the MME with Attach Type indicating “Handover” Attach. In step 4, the MME contacts the HSS and authenticates the UE. The MME receives information on the PDNs the UE is connected to over the non-3GPP access in the Subscriber Data obtained from the HSS.
In step 5, after successful authentication, the MME performs location update procedure and subscriber data retrieval from the HSS. Since the Attach Type is “Handover” Attach, the PDN GW address conveyed to the MME will be stored in PDN subscription context. In step 6, for connectivity to multiple PDNs, even if the UE had disconnected from the Default PDN before the handover, the MME selects a serving GW as described in TS 23.401 and sends a Create Default Bearer Request ( . . . , PDN-GW address, Handover Indication) message to the selected Serving GW. Since the Attach Type is “Handover” Attach, a Handover Indication information is included. In step 7, the Serving GW sends a Create Default Bearer Request (Handover Indication) message to the PDN-GW in the VPLMN or HPLMN. Since the MME includes Handover Indication information in Create Default Bearer Request message, the Serving GW includes this information in Create Default Bearer Request message. Since Handover Indication is included, the PDN GW should not switch the tunnel from non-3GPP IP access to 3GPP access system at this point.
In step 8, since Handover Indication is included, the PDN GW executes a PCEF-Initiated IP CAN Session Modification Procedure with the PCRF as specified in TS 23.203 to obtain the rules required for the PDN GW in the VPLMN or HPLMN to function as the PCEF for all the active sessions the UE has established with the new IP-CAN type as a result of the handover procedure. In step 9, the PDN GW responds with a Create Default Bearer Response message to the Serving GW. In step 10, the Serving GW returns a Create Default Bearer Response message to the MME. In step 11, Radio and Access bearers are established at this step in the 3GPP access. In step 12, the MME sends an Update Bearer Request ( . . . , Handover Indication) message to the Serving GW.
In step 13, since the Handover Indication is included in step 12), the Serving GW sends an Update Bearer Request message to the PDN GW to prompt the PDN GW to tunnel packets from non 3GPP IP access to 3GPP access system and immediately start routing packets to the Serving GW for the default and any dedicated EPS bearers established. In step 14, the PDN GW acknowledges by sending Update Bearer Response to the Serving GW. In step 15, the Serving GW acknowledges by sending Update Bearer Response message to the MME. In step 16, the UE sends and receives data at this point via the E-UTRAN system. In step 18, the PDN GW shall initiate resource allocation deactivation procedure in the trusted/untrusted non-3GPP IP access.
Step 3 of FIG. 9 implies that the BCE corresponding to all the flows is deleted, and step 18 of FIG. 10 implies that all resources on non-3GPP are released. However, in theory one could think of using the “handover” indication for the specific case where the “handover” indication is provided. In fact the UE may not delete the BCE and instead modify the BCE to setup some filters to forward some flows on the 3GPP access and some on the non-3GPP access. However, step 8 of FIG. 10 results also in updating PCC with the IP-CAN indication for the connection (before the handover it identifies the non-3GPP access and is now modified to 3GPP access), even if some flows are maintained over the non-3GPP access. This may result in incorrect charging, deletion of flows based on policies, and other unwanted behaviors.